home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Network Working Group Internet Activities Board
- Request for Comments: 1311 J. Postel, Editor
- March 1992
-
-
- Introduction to the STD Notes
-
- Status of this Memo
-
- This RFC describes a new sub-series of RFCs, called STDs (Standards).
- Distribution of this memo is unlimited.
-
- 1. Introduction
-
- The STDs are a subseries of notes within the RFC series that are the
- Internet standards. The intent is to identify clearly for the
- Internet community those RFCs which document Internet standards.
-
- 2. The Assignment of STD Numbers
-
- There is a need to be very clear about which specifications have
- completed the full process of standardization in the Internet. To do
- this an STD number will be assigned to a specification when it
- reaches the Standard maturity level. Note that specifications may be
- either Technical Specifications (TS) or Applicability Statements
- (AS).
-
- When a specification reaches the final stage of the standardization
- process and the IAB has designated it a standard for the Internet, an
- STD number will be assigned to that specification.
-
- The existing standards have been assigned STD numbers (see Appendix).
-
- The standard for a particular protocol will always have the same STD
- number.
-
- If at some future time a protocol is reworked and a new document
- is produced as the specification of that standard and the new
- specification is designated by the IAB as a standard for the
- Internet, then the new document will be labeled with the same STD
- number (of course, that new document will have a new RFC number).
-
- Multiple Documents for One Standard:
-
- A STD number identifies a standard not a document. A document is
- identified by its RFC number. If the specification of a standard
- is spread over several documents they will each carry the same STD
- number.
-
-
-
- Internet Activities Board [Page 1]
-
- RFC 1311 RFC on STD RFCs March 1992
-
-
- For example, the Domain Name System (DNS) is currently
- specified by the combination of RFCs 1034 and 1035. Both of
- these documents are now labeled STD-13.
-
- To be completely clear the DNS "Concepts and Facilities"
- document can be referenced as "STD-13/RFC-1034".
-
- In such cases, whenever possible, the set of documents defining a
- particular standard will cross reference each other.
-
- One Standard or Multiple Standards:
-
- One difficult decision is deciding whether a set of documents
- describe one standard or multiple standards. In the Appendix, one
- can see that there are several cases in which one STD applies to
- multiple RFCs (see STDs 5, 13, and 20). There is one case in
- which a family of specifications has multiple STD numbers; that is
- the Telnet Options.
-
- The general rule is that a separate STD number is used when the
- specification is logically separable. That is, logically
- separable options are assigned distinct STD numbers while
- amendments and non-optional extensions use the same STD number as
- the base specification.
-
- Multiple Versions or Editions of a Standard:
-
- It may occur that the documentation of a standard is updated or
- replaced with a new document. In such cases, the same STD number
- will be used to label the standard. No version numbers will be
- attached to STD numbers. There need be no confusion about having
- the up-to-date document about STD-9 since each version of the
- document will have a distinct RFC number (and of course a
- different date).
-
- The complete identification of a specification and its document is
- the combination of the STD and the RFC. For example, "STD-13/RFC-
- 1035" completely identifies the current version of the second part of
- the Domain Name System specification.
-
- To completely identify all of the DNS standard the citation would
- be "STD-13/RFC-1034/RFC-1035".
-
- One way to think of this is that an acronym (like TCP) refers to a
- concept, which is called a protocol. An RFC number (like RFC-793)
- indicates the specific version of the protocol specification. An STD
- number (like STD-7) designates the status of the protocol.
-
-
-
-
- Internet Activities Board [Page 2]
-
- RFC 1311 RFC on STD RFCs March 1992
-
-
- 2. Why an RFC Subseries ?
-
- There are several reasons why the STDs are part of the larger RFC
- series of notes.
-
- The foremost reason is that the distribution mechanisms for RFCs are
- tried and true. Anyone who can get an RFC, can automatically get a
- STD. More important, anyone who knows of the RFC series can easily
- find the STDs.
-
- Another reason for making STDs part of the RFC series is that the
- maintenance mechanisms for RFCs are already in place. It makes sense
- to maintain similar documents is a similar way.
-
- 3. Format Rules
-
- Since the STDs are a part of the RFC series, they must conform to
- "Request for Comments on Request for Comments: Instructions to RFC
- Authors" (RFC-1111) with respect to format.
-
- 3.1 Status Statement
-
- Each STD RFC must include on its first page the "Status of this Memo"
- section which contains a paragraph describing the intention of the
- RFC. This section is meant to convey the status approved by the
- Internet Activities Board (IAB).
-
- 3.2. Distribution Statement
-
- Each STD RFC will also include a "distribution statement". As the
- purpose of the STD series is to disseminate information, there is no
- reason for the distribution to be anything other than "unlimited".
-
- Typically, the distribution statement will simply be the sentence
- "Distribution of this memo is unlimited." appended to the "Status of
- this Memo" section.
-
- 3.3. Security Considerations
-
- All STD RFCs must contain a section that discusses the security
- considerations of the procedures that are the main topic of the RFC.
-
- 3.4. Author's Address
-
- Each STD RFC must have at the very end a section giving the author's
- address, including the name and postal address, the telephone number,
- and the Internet email address.
-
-
-
-
- Internet Activities Board [Page 3]
-
- RFC 1311 RFC on STD RFCs March 1992
-
-
- In the case of multiple authors, each of the authors will be listed.
- In the case of a document produced by a group, the editor of the
- document will be listed and optionally the chair of the group may be
- listed.
-
- 4. The STD Publication
-
- New documents can only become STD RFCs through an action of the IAB.
- The publication of STDs will be performed by the RFC Editor.
-
- 5. STD Announcements
-
- New STD RFCs are announced to the RFC distribution list maintained by
- the Network Information Center (NIC). Contact the NIC to be added or
- deleted from this mailing list by sending an email message to RFC-
- REQUEST@NIC.DDN.MIL.
-
- 6. Obtaining STDs
-
- STD RFCs may be obtained in the same way as any RFC.
-
- Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
- an EMAIL message to "rfc-info@ISI.EDU" with the message body "help:
- ways_to_get_rfcs". For example:
-
- To: rfc-info@ISI.EDU
- Subject: getting rfcs
-
- help: ways_to_get_rfcs
-
- The current standards are listed in the "IAB Official Protocol
- Standards" (which is STD-1), whose current edition is RFC-1280.
-
- Security Considerations
-
- Security issues are not discussed in this memo.
-
- Author's Address
-
- Jon Postel
- USC/Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, CA 90292
-
- Phone: 310-822-1511
- Fax: 310-823-6714
-
- Email: Postel@ISI.EDU
-
-
-
- Internet Activities Board [Page 4]
-
- RFC 1311 RFC on STD RFCs March 1992
-
-
- APPENDIX -- The Grandfathered STDs
-
- Protocol Name Status RFC STD
- ======== ===================================== ======= ===== ====
- -------- IAB Official Protocol Standards Req 1280 1
- -------- Assigned Numbers Req 1060 2
- -------- Host Requirements Req 1122,1123 3
- -------- Gateway Requirements Req 1009 4
- IP Internet Protocol Req 791 5
- as amended by:
- -------- IP Subnet Extension Req 950 5
- -------- IP Broadcast Datagrams Req 919 5
- -------- IP Broadcast Datagrams with Subnets Req 922 5
- ICMP Internet Control Message Protocol Req 792 5
- IGMP Internet Group Multicast Protocol Rec 1112 5
- UDP User Datagram Protocol Rec 768 6
- TCP Transmission Control Protocol Rec 793 7
- TELNET Telnet Protocol Rec 854,855 8
- FTP File Transfer Protocol Rec 959 9
- SMTP Simple Mail Transfer Protocol Rec 821 10
- MAIL Format of Electronic Mail Messages Rec 822 11
- CONTENT Content Type Header Field Rec 1049 11
- NTP Network Time Protocol Rec 1119 12
- DOMAIN Domain Name System Rec 1034,1035 13
- DNS-MX Mail Routing and the Domain System Rec 974 14
- SNMP Simple Network Management Protocol Rec 1157 15
- SMI Structure of Management Information Rec 1155 16
- MIB-II Management Information Base-II Rec 1213 17
- EGP Exterior Gateway Protocol Rec 904 18
- NETBIOS NetBIOS Service Protocols Ele 1001,1002 19
- ECHO Echo Protocol Rec 862 20
- DISCARD Discard Protocol Ele 863 21
- CHARGEN Character Generator Protocol Ele 864 22
- QUOTE Quote of the Day Protocol Ele 865 23
- USERS Active Users Protocol Ele 866 24
- DAYTIME Daytime Protocol Ele 867 25
- TIME Time Server Protocol Ele 868 26
-
- Telnet Options Option Status RFC STD
- ======== ================================= ====== ======= ===== ====
- TOPT-BIN Binary Transmission 0 Rec 856 27
- TOPT-ECHO Echo 1 Rec 857 28
- TOPT-SUPP Suppress Go Ahead 3 Rec 858 29
- TOPT-STAT Status 5 Rec 859 30
- TOPT-TIM Timing Mark 6 Rec 860 31
- TOPT-EXTOP Extended-Options-List 255 Rec 861 32
-
-
-
-
-
- Internet Activities Board [Page 5]
-
-